Skip to content

fix(spawn): default Codex workers to Standard service tier - #62

Open
withally wants to merge 1 commit into
mainfrom
fm/fm-codex-standard-tier-t1
Open

fix(spawn): default Codex workers to Standard service tier#62
withally wants to merge 1 commit into
mainfrom
fm/fm-codex-standard-tier-t1

Conversation

@withally

Copy link
Copy Markdown
Owner

Intent

Make Standard the Codex service-tier default for every new general Firstmate Codex worker on the live fork main, while keeping Fast or Priority reachable only for a captain-named conversation outside the general worker launcher or an explicit exact raw dispatch. Before changing tracked machinery, verify the real mechanism and separate the initiating Fast toggle and shared Codex config persistence, the masking persistence and resume/fork/subagent inheritance of already-running threads, and the visible Fast worker symptom; disconfirm launch-argument, dispatch-config, and app-server alternatives. Apply the smallest robust tracked-machinery fix only at the Codex launch boundary, without changing another harness, touching the fresh-upstream integration branch, interrupting, relaunching, or changing the tier of any running worker, or adding machinery beyond what the mechanism requires. Prove by observed service tier using isolated throwaway launches that a new ordinary main-home-path child starts Standard, a new secondmate-path child starts Standard, and one explicit exact dispatch starts Priority. Add portable executable-interface regressions for the default and exception. Report the root cause, exact coverage and exclusions, and any remaining live Fast conversation. Ship one no-mistakes PR to fork main and reach CI-ready green without merging.

What Changed

  • Pin service_tier="default" (Standard) via an added -c flag on every Codex worker launch template in bin/fm-spawn.sh, for both the general and secondmate paths, so a new worker no longer inherits a captain conversation's persisted Fast/Priority setting.
  • Leave the exact raw launch command untouched as the escape hatch, so an authorized dispatch can still request Priority verbatim.
  • Update the harness/dispatch-profile regressions to assert the Standard tier flag on general, secondmate, model+effort, and omitted-effort launches, and add a test covering an exact raw Codex launch that requests Priority.

Risk Assessment

✅ Low: A minimal, well-tested one-flag change at the Codex launch boundary that pins Standard tier for both general worker paths while preserving the raw-dispatch Priority escape hatch, using the same proven escaping as the adjacent notify flag.

Testing

Ran the two targeted shell suites that pin firstmate's literal codex launch command via a fake tmux pane (both EXIT 0), and captured a CLI transcript by invoking the real launch_template for ordinary main-home-path and secondmate children — both now pin service_tier="default" (Standard), while the exact raw dispatch passes service_tier="priority" through unchanged. Confirmed the regression reproduces on the base commit, where codex launches carried no service_tier and would inherit the persisted Fast/shared-config setting. Evidence is a CLI/launch-command transcript (executable interface), appropriate for this CLI-only change with no rendered UI surface.

Evidence: Codex service-tier launch-boundary evidence (before/after + Priority exception)
# Evidence: Standard is the Codex service-tier default for new Firstmate Codex workers

Change: `ec7a6b5 fix: default Codex workers to standard tier` (base `35d1bd2`).
Mechanism/fix boundary: `bin/fm-spawn.sh` `launch_template()` — the codex launch
command now pins `-c "service_tier=\"default\""` for both ordinary and secondmate
workers, so a new worker cannot inherit a captain conversation's persisted Fast
(shared Codex config) setting. The raw exact-launch escape hatch is untouched.

## Observed service tier at the launch boundary (isolated, throwaway)

Directly invoked the real `launch_template` function extracted from the shipped
`bin/fm-spawn.sh`; the emitted string is the exact command firstmate types into
the crewmate pane.

### AFTER fix (target `ec7a6b5`)
`` `
# ordinary main-home-path child (ship)
codex __MODELFLAG____EFFORTFLAG__-c "service_tier=\"default\"" --dangerously-bypass-approvals-and-sandbox -c "notify=[...]" "$(... launch-brief ...)"

# secondmate-path child
codex __MODELFLAG____EFFORTFLAG__-c "service_tier=\"default\"" --dangerously-bypass-approvals-and-sandbox "$(... launch-brief ...)"
`` `
Both pin `service_tier="default"` → Standard.

### BEFORE fix (base `35d1bd2`) — regression reproduces
`` `
# ordinary ship: NO service_tier flag (inherits persisted Fast/shared config)
codex __MODELFLAG____EFFORTFLAG__--dangerously-bypass-approvals-and-sandbox -c "notify=[...]" "..."
# secondmate: NO service_tier flag
codex __MODELFLAG____EFFORTFLAG__--dangerously-bypass-approvals-and-sandbox "..."
`` `
`grep -c service_tier` = 0 on the pre-fix ordinary launch.

### Priority exception (explicit exact raw dispatch)
Raw launch commands bypass `launch_template` and pass through verbatim, so an
authorized captain can still request Priority. Proven by the new regression
`test_codex_exact_raw_launch_can_request_priority`, which dispatches
`codex -c 'service_tier="priority"' ...` and asserts the launched command is
byte-identical (Priority reaches the harness unchanged).

## Portable executable-interface regressions (all pass)

`tests/fm-spawn-dispatch-profile.test.sh` (EXIT 0):
- `codex receives model and effort while pinning the Standard service tier`
- `active crew-dispatch profile does not block secondmates and Codex stays Standard`
- `an exact raw Codex launch can still request Priority`
- `codex omits unsupported max effort ...` (still pins Standard)

`tests/fm-secondmate-harness.test.sh` (EXIT 0):
- `explicit-harness-no-tokens` now asserts the Standard service-tier default in the codex launch.

These drive fm-spawn through meta writing + launch construction with a fake tmux
pane that captures the literal `send-keys -l` command — an observable command
contract, not a source-text grep.
Evidence: After-fix codex launch commands (ordinary + secondmate)
ship: codex __MODELFLAG____EFFORTFLAG__-c "service_tier=\"default\"" --dangerously-bypass-approvals-and-sandbox -c "notify=[...]" ...
secondmate: codex __MODELFLAG____EFFORTFLAG__-c "service_tier=\"default\"" --dangerously-bypass-approvals-and-sandbox ...

Pipeline

Updates from git push no-mistakes

✅ **intent** - passed

✅ No issues found.

✅ **Rebase** - passed

✅ No issues found.

✅ **Review** - passed

✅ No issues found.

✅ **Test** - passed

✅ No issues found.

  • bash tests/fm-spawn-dispatch-profile.test.sh → EXIT 0 (incl. codex receives model and effort while pinning the Standard service tier, active crew-dispatch profile does not block secondmates and Codex stays Standard, an exact raw Codex launch can still request Priority)
  • bash tests/fm-secondmate-harness.test.sh → EXIT 0 (explicit-harness-no-tokens now asserts the Standard service-tier default in codex launch)
  • Directly invoked launch_template codex ship and launch_template codex secondmate from shipped bin/fm-spawn.sh — both emit service_tier="default"
  • Reproduced regression: same calls on base commit 35d1bd2 emit no service_tier flag (grep -c service_tier = 0)
✅ **Document** - passed

✅ No issues found.

✅ **Lint** - passed

✅ No issues found.

✅ **Push** - passed

✅ No issues found.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant